The Internet is a vast and expanding network of networks of computers and other devices linked together by various telecommunications media, enabling all these computers and other devices to exchange and share data. Sites on the Internet provide information about a myriad of corporations and products, as well as educational, research and entertainment information and services. An estimated 30 million people worldwide use the Internet today, with 100 million predicted to be on the “net” in a matter of years.
A computer or resource that is attached to the Internet is often referred to as a “host.” Examples of such resources include conventional computer systems that are made up of one or more processors, associated memory (typically volatile and non-volatile) and other storage devices and peripherals that allow for connection to the Internet or other networks (e.g., modems, network interfaces and the like). In most cases, the hosting resource may be embodied as hardware and/or software components of a server or other computer system that includes an interface, which allows for some dialog with users thereof. Generally, such a server will be accessed through the Internet (e.g., via Web browsers such as Netscape's Navigator™ and Communicator™ and Microsoft's Internet Explorer™) in the conventional fashion.
Briefly, if an Internet user desires to establish a connection with a host (e.g., to view a Web page located thereat), the user might enter into a Web browser program the URL (or Web address) corresponding to that host. One example of such a URL is “http://www.domain.com”. In this example, the first element of the URL is a transfer protocol (most commonly, “http” standing for hypertext transfer protocol, but others include “mailto” for electronic mail, “ftp” for file transfer protocol, and “nntp” for network news transfer protocol). The remaining elements of this URL (in this case, “www” standing for World Wide Web—the Internet's graphical user interface—and “domain.com”) are an alias for the “fully qualified domain name” of the host.
Each fully qualified domain name, in its most generic form, includes three elements. Taking “computer.host.com” as an example, the three elements are the hostname (“computer”), a domain name (“host”) and a top-level domain (“com”). Further, each fully qualified domain name is unique throughout the Internet and corresponds to a numerical Internet protocol (IP) address. IP addresses facilitate communications between hosts and clients in the same way that physical addresses (e.g., 123 Main Street, Anytown, Anycity) facilitate correspondence by mail. Each IP address is made up of four groups of numbers separated by decimals. Thus, in the case of the hypothetical host “computer.domain.com”, the corresponding IP address might be 123.456.78.91. A given host looks up the IP addresses of other hosts on the Internet through a system known as domain name service.
Thus, once a URL is entered into a browser, the corresponding IP address is looked up in a process facilitated by a top-level server. In other words, all queries for addresses are routed to certain computers, the so-called top-level servers. The top-level server matches the domain name to an IP address of a domain name server capable of directing the inquiry to the computer hosting the sought after Web page (or other content) by matching an alphanumeric name such as www.domain.com with its numeric IP address.
In addition to Web pages and the like, more and more Internet users are accessing multimedia content (e.g., files that include high quality graphical images, movies and/or sound). This creates difficulties because such files are usually quite large while the bandwidth available through the Internet is limited. Thus, in order to make multimedia files usable, streaming is often employed.
With conventional files (e.g., data files), clients (e.g., Web browsers) completely download the requested content before viewing it. This technique works well for relatively small files, but often suffers from unacceptable (from the point of view of the user) delays when large multimedia files are involved. Streaming is the term given to a technique wherein a client downloads a portion of a file, decompresses (if necessary) that portion, and starts playing the contents thereof (e.g., audio and/or video) before the rest of the file arrives. A buffer of information is built up before playback starts, so as to prevent underflows if the remaining data is delayed during transmission. Furthermore, subsequent portions of the multimedia file are downloaded during playback to keep the buffer relatively full. This technique thus accommodates the downloading and playing of large multimedia files without incurring lengthy delays before the content is available for viewing.
Multimedia files are often transported over the Internet using special transport protocols. For example, the real-time transport protocol (RTP) provides delivery service for multimedia applications and also provides means for multimedia applications to work over networks. RTP does not, however, provide guaranteed or in-sequence delivery (and hence it is referred to as an unreliable transport protocol), but does provide a packet sequence number that can be used to detect missing packets and to reconstruct an original transmission sequence.
RTP usually carries data in the form of packets, using the user datagram protocol (UDP) as the delivery mechanism. UDP provides a “wrapper” around data packets, with the wrapper providing for multiplexing and demultiplexing as well as error checking services. Essentially, a UDP packet is made up of a UDP header and UDP data encapsulated as the data portion of an IP packet. The IP packet itself includes an IP header (which includes the address information discussed above) as well as the user data (i.e. the multimedia content of interest) as a payload.
In some cases, RTP is used with other protocols, such as the transmission control protocol (TCP). Unlike UDP, TCP provides a reliable, error-free, full-duplex channel between two computers. TCP uses IP to transfer data, but provides mechanisms to take care of lost or duplicated IP datagrams (i.e., packets) and to ensure proper sequencing thereof. Thus, TCP provides reliable end-to-end transport, ensuring that what is received is an exact duplicate of what is transmitted.
When an application starts an RTP session, a second port for communication according to the real time control protocol (RTCP) is opened. RTCP works in conjunction with RTP to provide flow control and congestion control services. The idea is that the exchange of RTCP packets between a client and server can be used to adjust the statistics and/or rate of transmission of the RTP packets, etc.
Associated with RTP is the real time streaming protocol (RTSP). RTSP is a client-server multimedia presentation control protocol that control functionality such as content type, interactive stream control, error mitigation, bandwidth negotiation, multicast, live broadcasting and monitoring. Just as HTTP transports HTML (hypertext markup language—an instruction set that allows an HTTP client to render a desired image, etc.), RTSP handles multimedia data. The difference is that while HTTP clients always make requests and HTTP servers always service those requests, RTSP is bi-directional, with both servers and clients making requests and servicing them. RTSP accomplishes data transfer using TCP or UDP.
Thus, RTSP is a generally a TCP connection over which commands are sent and responses are returned. Clients negotiate data channels with servers via SETUP commands. These channels typically specify that data will be sent as RTP/RTCP “packets”, but the transport type may be specified and/or modified as part of the negotiation. Further, the negotiations may determine whether the packets will be sent over TCP (e.g., as binary packet data imbedded in an RTSP command stream via an escape sequence) or UDP (e.g., as true packets).
The RTP portion of a channel contains actual media data for single stream flows (e.g., compressed audio data). In contrast, an RTCP portion of a channel (which typically is assigned one UDP port number or TCP channel number larger than the RTP port number or channel—for example, UDP port 6970 for RTP and 6971 for RTCP) usually contains clock-synchronization data and client-server control/status messages. As indicated above, RTP data typically flows in one direction, from the server to the client. RTCP packets are typically sent in both directions, for example as client status report messages and server status report messages.
The following dialog illustrates (from a client's point of view) a portion of an RTSP session wherein a media description is retrieved and the single audio stream specified thereby is played. Those of ordinary skill in the art will recognize that this is a “live” stream as opposed to prerecorded content, as is evident from the absence of a “range” tag in the session description protocol (SDP). In the initial client-to-server communication, a request to describe the stream located at a particular Web address (rtsp://qt.macroradio.net/gogaga) is sent, along with suggested connection parameters, such as a bandwidth:    Send data (130 bytes).    <00000000< DESCRIBE rtsp://qt.macroradio.net/gogaga RTSP/1.0    <00000033< CSeq: 1    <0000003C< Accept: application/sdp    <00000055< Bandwidth: 112000    <00000068< User-Agent: QTS/1.0b22    <00000080<    The server responds with a description of the stream as part of an SDP:    Receive data (566 bytes).    >00000000> RTSP/1.0 200 OK    >00000011> Server: QTSS/v65    >00000023> Cseq: 1    >0000002C> Content-Type: application/sdp    >0000004B> Content-Base: rtsp://qt.macroradio.net/gogaga/    >0000007B> Content-length: 420    >00000090>    >00000092> v=0    >00000097> o=3134316689 3134906918 IN IP4 192.231.139.83    >000000C7> s=GoGaGa Brand Radio    >000000> i=<<A9>>1999—All rights reserved—    >000000FF> u=http://www.macroradio.net    >0000011C> a=x-qt-text-nam:GoGaGa Brand Radio    >00000140> a=x-qt-text-cpy:<<A9>>1999—All rights reserved    >0000016D> a=x-qt-text-cpy:(c) 1999 ERC: The Eclectic Radio Company,    >000001A7> LLC.    >000001AD> t=3134316689 3134320289    >000001C6> c=INP4 0.0.0.0    >000001D8> a=control:*    >000001E5> m=audio 0 RTP/AVP 97    >000001FB> a=rtpmap:97 X-QT    >0000020D> a=x-bufferdelay:10    >00000221> a=control:trackID=1The client then defines conditions for a playback, using a specified port:    Send data (143 bytes).    <00000082< SETUP rtsp://qt.macroradio.net/gogaga/trackID=1 RTSP/1.0    <000000BC< CSeq: 2    <0000000C5< Transport: RTP/AVP;unicast;client_port=6970-6971    <000000F7< User-Agent: QTS/1.0b22    <0000010F<    The server responds with the port address from which it will play:    Receive data (165 bytes).    >00000236> RTSP/1.0 200 OK    >00000247> Server: QTSS/v65    >00000259> Cseq: 2    >00000262> Session: 1411920655; timeout=60    >00000282> Transport: rtp/avp;source=192.231.139.182; server_port=2000-2001;    >000002C2> client_port=6970-6971    >000002D9>The client then initiates play back using the specified port addresses:    Send data (125 bytes).    <00000111< PLAY rtsp://qt.macroradio.net/gogaga RTSP/1.0    <00000140< CSeq: 3    <00000149< Range: npt=0.000000—    <0000015F< Session: 1411920655    <00000174< User-Agent: QTS/1.0b22    <0000018C<In response, the server begins playing the selected stream:    Receive data (92 bytes).    >000002DB> RTSP/1.0 200 OK    >000002EC> Server: QTSS/v65    >000002FE> Cseq: 3    >00000307> Session: 1411920655    >0000031C> RTP-Info: url=trackID=1    >00000335>
At this point, RTP media data and RTCP control packets will start flowing between the specified UDP ports, i.e., RTP data from server port 2000 to client port 6970, and RTCP packets between server port 2001 and client port 6971. Note that the server's address 192.231.139.182 can be seen in the SETUP response above. An example of an RTCP packet transmitted from the client (port 6971) to the server (port 2001) is shown below:
Send packet data to port 1 (84 bytes).<00000000< 80 C9 00 01 00 00 62 76 81 CA 00 12 00 00 62 76......bv......bv<00000010< 01 0D 51 54 53 20 38 30 35 32 31 38 36 39 33 02..QTS 805218693.<00000020< 13 51 75 69 63 6B 54 69 6D 65 20 53 74 72 65 61.QuickTime Streaming<00000030< 6D 69 6E 67 06 1A 51 75 69 63 6B 54 69 6D 65 20..QuickTime<00000040< 53 74 72 65 61 6D 69 6E 67 2F 31 2E 30 62 32 32Streaming/1.0b22<00000050< 00 00 00 D2          ....If one were to decode the data, it may translate to “client received 5% loss and 123456 bytes and client “name” is ‘QuickTime Streaming’ client”.
An RTCP packet sent from the server (port 2001) to the client (port 6971) may resemble the following:
Receive packet data from 192.231.139.182:2001 (108 bytes).>00000000> 80 C8 00 06 00 00 45 38 BA F0 68 00 42 1F 8E 44......E8..h.B..D>00000010> 3D 25 45 EB 00 E7 A3 3F BB 8C 3A 78 81 CA 00 13=% E....?..:x....>00000020> 00 00 45 38 01 18 51 54 53 40 6C 6F 63 61 6C 68..E8..QTS @ localhost>00000030> 6F 73 74 20 31 35 36 31 36 31 35 34 36 39 02 131561615469..>00000040> 51 75 69 63 6B 54 69 6D 65 20 53 74 72 65 61 6DQuickTime Streaming>00000050> 69 6E 67 06 13 51 75 69 63 6B 54 69 6D 65 20 53..QuickTime>00000060> 74 72 65 61 6D 69 6E 67 00 FF 00 40Streaming... @Once decoded, this information may state, “RTP time t means universal (wall clock) time y and server “name” is “QuickTime Streaming server”. This is essentially a reference to an absolute reference time source used by the server.
The actual RTP media packets transmitted from the server (port 2000) to the client (port 6970) may resemble the following:
Receive packet data from 192.231.139.182:2000 (200 bytes).>00000000> 80 E1 BC 73 3D 21 F8 1B 00 00 45 38 14 00 80 01...s=!....E8....>00000010> 02 B6 4B 19 09 14 80 9E 5D 26 35 24 88 64 2A 20..K.....]&5$.d*>00000020> D0 C2 98 16 92 55 41 9C 82 46 16 35 9D A8 D7 27.....UA..F.5...′>00000030> 13 1A B7 37 D6 E4 05 5B 40 AF E7 11 D3 84 9C B8...7...[@.......>00000040> 45 8D 51 01 F1 A4 C5 97 0B 58 88 2A 4A D1 C4 13E.Q......X.*J...>00000050> FC 8C 58 A5 46 8A A2 3B 63 66 6F 23 2F 38 1B 61..X.F..;cfo#/8.a>00000060> 0B 15 2A D3 49 22 C9 98 C8 0F 16 40 1A 53 9D A8..*.I″.....@.S..>00000070> 79 F1 CE EE C6 19 B1 26 C5 A8 CB 4D 4B 3B F3 73y......&...MK;.s>00000080> 4C 6A 33 5F D3 5F 2C 46 60 84 C0 08 14 14 26 ECLj3_._,F′.....&.>00000090> 5E DF 49 49 48 B5 B3 02 5F 88 F5 EC 29 10 AB 72{circumflex over ( )}.IIH..._...)..r>000000A0> A6 D8 3E D4 9A D2 14 2A 6F 86 AD 22 9E 0B 4C 50..>....*o..″..LP>000000B0> 5C BC 0B 88 6D 13 0C 34 3C 44 CB 92 BB 6B 1B 18\...m..4<D...k..>000000C0> 51 1C 7D 12 01 00 00 00Q.}.....
Finally, upon conclusion of the playback or at some other point, the client may decide to quit, so an instruction is passed to server over RTSP (the TCP connection is still open during the playback) to stop everything on this “session”:    Send data (107 bytes).    <0000018E< TEARDOWN rtsp://qt.macroradio.net/gogaga RTSP/1.0    <000001C1< CSeq: 4    <000001CA< Session: 1411920655    <000001DF< User-Agent: QTS/1.0b22    <000001F7<
Although these and other transport protocols exist, there still exist problems with the viewing of streaming content over public networks or networks of networks such as the Internet. For example, whenever unreliable transport protocols (e.g., RTP) are used, there can be significant data loss between the content source (e.g., the server) and the content consumer (i.e., the client), depending on the network traffic conditions. If this loss is high (e.g., 10% or more), the viewing quality can be degraded to the point where it is unacceptable to a user.
This problem can be exaggerated as more and more users attempt to download content across a network, as shown in FIG. 1. In general, when seeking to view streaming content over an Internet or other network connection, a user 10 will connect to the content's source (e.g., server 12). This connection 14 will allow for the transport of the streaming content, usually according to one of the protocols for multimedia transmission discussed above. Now, when a second user 16 wishes to view the same broadcast, he or she will open a separate connection 18 across the network (e.g., the Internet) 20 to server 12. Thus, the content that is being downloaded by user 10 is the same content that is being downloaded by user 16. This duplication of material adds to network congestion and (especially as this scenario is repeated many times over for further users) can contribute to packet loss on each of the connections.
Others have attempted to solve this problem,(improved viewing quality or, more generally, improved user experience in the face of data loss), but have primarily concentrated on trying to make the transport of information from source to client more reliable. Thus, for example, others have attempted to use TCP rather than UDP as the transmission protocol. Although TCP guarantees that all packets that make up a file will arrive and will be in sequence when ultimately played out, it does so by requesting retransmissions of any lost packets. This not only introduces delay into any playback (e.g., while waiting for lost packets to be retransmitted), it also adds to the total volume of network traffic thus leading to still further packet loss due to congestion and the like. The delays introduced by the use of TCP often mean that the ultimate user experience is poor, and perhaps even less acceptable than would be the case if lost packets were simply overlooked.
Other solutions have proposed using network bandwidth reservation protocols in place of unreliable transmission protocols. Unfortunately, such protocols are not always available end-to-end, and so this solution is not always an option.
Another strategy for dealing with the loss of data between the source and the requesting client is to control the amount of data being transmitted. Where possible, clients that are experiencing significant data loss may instruct the server to send less data. Thus, in the scenario of a streaming movie, the server may be instructed to send only key frames and not any (or perhaps just a few) difference frames. However, this strategy is only successful where the data loss is due to actual bandwidth overloading at the client and not due to other factors in the intervening network. For example, if the packet loss is due to consistent buffer overflow at the receiver, instructing the server to send less data may prevent such overflows and provide a better user experience. Where, however, packet loss is due to overall network congestion, instructing the server to send less data will have no effect on the packet loss, because the insignificant reduction in the total number of packets within the network due to the stream under consideration will not be sufficient to dramatically affect the packet loss rate for that stream. The net result will simply be roughly the same packet loss rate over a fewer number of transmitted packets—leading to an even worse condition.
What is needed, therefore, is a new solution to the problem of dealing with data loss during downloading of streaming content.